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(54) Centralized cerificate management system for two-way interactive communication devices 
in data networks 



(57) The present invention discloses a method for 
managing centralized certificates in a proxy server de- 
vice (114) for a plurality of thin client devices (302, 304, 
306) coupled thereto through a data network (102). A 
user account database, accessible by the proxy server, 
comprises a plurality of user accounts with each of the 
thin client devices being associated with one or more of 
the user accounts. Each of the user accounts comprises 
a device ID (316), a list of public and private keys (326) 
assigned to the user account, and a list of certificates 
(320) assigned to the user account. A certificate man- 



agement module reserves a fixed number of free certif- 
icates signed by a Certificate Authority and their respec- 
tive private keys in a certificate database (328) and fre- 
quently updates the free certificate according to a cer- 
tificate updating message. Whenever a user account is 
created for a thin client device, the certificate manage- 
ment module fetches one or more free certificates from 
the certificate database and associates the fetched cer- 
tificate^) to the created account and at the same time 
creates new free certificates with the Certificate Author- 
ity to fill in the certificate database. 
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Description 

BACKGROUND OF THE INVENTION 

Field of Invention s 

[0001] The present invention relates to data security 
between server computers and client computers in data 
networks, and more particularly relates to systems for 
managing, in a proxy server computer, digital certifi- io 
cates for two-way interactive communication devices 
over the data networks; wherein the two-way interactive 
communication devices, such as mobile devices, cellu- 
lar phones, landline telephones and Internet appliance 
controllers, have generally limited computing resources ts 
such as computing power, memory and graphical dis- 
play capability. 

Description of the Related Art 

20 

[0002] A fast-growing trend on the Internet is electron- 
ic commerce. The electronic commerce is an integrative 
concept designed to draw together a wide range of busi- 
ness support services, trading support systems for com- 
modities, products, customized products and custom- 25 
built goods and services; ordering and logistic support 
systems; settlement support systems; and manage- 
ment information and statistical reporting systems, alt 
via the Internet. It is well known, however, that the Inter- 
net is a wide open, public and international network of 30 
interconnected computers and electronic devices 
around the world. The ability to send and receive secure 
data becomes a fundamental requirement in conducting 
electronic commerce over the Internet. To transact busi- 
ness over the open network, a business or organization 35 
must have an efficient and reliable manner to establish 
its identity and credibility to protect itself and its custom- 
ers from imposters. Similarly, customers need assur- 
ance that their private information they may submit over 
the Internet can not be read by anyone but the business 40 
that they submit to. 

[0003] One of the on-going efforts to ensure private 
communications or business transactions between two 
authenticated parties is to use digital certificates to bind 
the identities of the two parties to a pair of electronic 4S 
keys that can be used to encrypt and sign digital infor- 
mation transmitted over the Internet. A digital certificate 
makes it possible to verify someone's claim that they 
have the right to use a given key, which helps prevent 
others from using phony keys to impersonate authorized so 
users. Used in conjunction with encryption, digital cer- 
tificates provide a more complete security solution by 
assuring the identity of all parties involved in a transac- 
tion through an open network. 

[0004] The current architecture for using the digital 55 
certificates is binding between two computers, one be- 
ing a client computer and the other being a server com- 
puter, on the Internet, that means both computers phys- 
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ically hold their own certificates, requiring a memory 
space to keep certificates. In case, one of the certificates 
becomes invalid (expired, revoked or no longer usable), 
the computer that owns the invalid certificate may ac- 
quire a new certificate from a certificate issuing author- 
ity. However, the acquiring process generally takes a 
number of minutes and a significant amount of comput- 
ing power. When a communication session between the 
two computers is established, the two computers au- 
thenticate each other by examining the counterpart's 
certificate. A session key is created when the authenti- 
cation is successful and a secure communication ses- 
sion thus commences using the session key to encrypt 
all information exchanging between the two computers. 
The authentication process also takes a significant 
amount of computing power. 

[0005] When the client computer is a small two-way 
communication device such as a mobile computing de- 
vice, a cellular phone, a landline telephone, or an Inter- 
net appliance controller, the above architecture is hardly 
applicable. To increase the portability and mobility, most 
of such two-way communication devices are designed 
small in size, light in weight, low in power consumption 
and as economically as possible. Such designs, often 
considered as thin designs, result in a very limited com- 
puting power, typically equivalent to less than one per- 
cent of what is provided in a typical desktop or portable 
computer and the memory capacity thereof is generally 
less than 250 kilobytes. That means that the thin client 
devices would not have extra memory spaces to store 
a number of certificates and the required computing 
power to acquire a new certificate in real time if one of 
the possessed certificates becomes invalid. There is 
thus a great need for providing the thin clients with a 
mechanism to effectively manage the certificates. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0006] These and other features, aspects, and advan- 
tages of the present invention will become better under- 
stood with regard to the following description, appended 
claims, and accompanying drawings where: 

Figure 1 illustrates, as an exemplary illustration, 
how the certificates are being used between a client 
device and a merchant server; 

Figure 2 illustrates a schematic representation of a 
mobile data network comprising an airnet and a 
landnet, in which the present invention may be prac- 
tised; 

Figure 3 illustrates a representation of the present 
invention interacting with other parts or components 
in the data network; 

Figures 4A and 4B demonstrate an example in 
which a user of a mobile device requests certificates 
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from a user-specified CA; 

Figure 5 depicts a block diagram of various compo- 
nents in a certificate management module in the 
present invention; and 

Figures 6A and 6B illustrate an operation flowchart 
showing processes and procedures for managing 
certificates in a server device for thin clients over a 
data network. 

DETAILED DESCRIPTION OF THE INVENTION 

Notation and Nomenclature 

[0007] In the following detailed description of the 
present invention, numerous specific details are set 
forth in order to provide a thorough understanding of the 
present invention. However, it will become obvious to 
those skilled in the art that the present invention may be 
practised without these specific details. In other instanc- 
es, well known methods, procedures, components, and 
circuitry have not been described in detail to avoid un- 
necessarily obscuring aspects of the present invention. 
[0008] The detailed description of the present inven- 
tion in the following are presented largely in terms of 
procedures, steps, logic blocks, processing, and other 
symbolic representations that resemble of data 
processing devices coupled to networks. These process 
descriptions and representations are the means used 
by those experienced or skilled in the art to most effec- 
tively convey the substance of their work to others 
skilled in the art. The present invention is a centralized 
certificate management system for two-way interactive 
communication devices in data networks. The method 
along with the architecture to be described in detail be- 
low is a self-consistent sequence of processes or steps 
leading to a desired result. These steps or processes 
are those requiring physical manipulations of physical 
quantities. Usually, though not necessarily, these quan- 
tities may take the form of electrical signals capable of 
being stored, transferred, combined, compared, dis- 
played and otherwise manipulated in a computer sys- 
tem or electronic computing devices. It proves conven- 
ient at times, principally for reasons of common usage, 
to refer to these signals as bits, values, elements, sym- 
bols, operations, messages, terms, numbers, or the like. 
It should be borne in mind that all of these similar terms 
are to be associated with the appropriate physical quan- 
tities and are merely convenient labels applied to these 
quantities. Unless specifically stated otherwise as ap- 
parent from the following description, it is appreciated 
that throughout the present invention, discussions uti- 
lizing terms such as "processing" or "computing" or "ver- 
ifying" or "displaying" or the like, refer to the actions and 
processes of a computing device that manipulates and 
transforms data represented as physical quantities with- 
in the computing device's registers and memories into 



other data similarly represented as physical quantities 
within the computing device or other electronic devices. 

Introduction to Digital Certificates 

5 

[0009] A digital certificate or certificate, sometimes re- 
ferred as digital ID or security certificate, is a piece of 
information, often stored as a text file, to be used by the 
secure sockets layer (SSL) protocol to establish a se- 

io cure connection between two parties over an open data 
network. In the simplest form, a certificate contains a 
public key and a name. As commonly used, a certificate 
also contains an expiration date, the name of the certi- 
fying authority that issued the certificate, a serial 

is number, and perhaps other information. Most important- 
ly, it contains the digital signature of the certificate issu- 
er, i.e. an encrypted "fingerprint" that can be used to ver- 
ify the contents of the certificate. 
[0010] A digital certificate, or simply certificate, is is- 

20 sued by a Certification Authority (CA) and signed with 
the CA's private key. The most widely accepted format 
for Digital IDs is defined by the CCITT X.509 interna- 
tional standard; thus certificates can be read or written 
by any application complying with the CCITT X.509. A 

25 digital certificate uses public key encryption techniques 
that are based on a pair of related keys, a public key 
and a private key. In public key encryption, the public 
key is made available to anyone who wants to corre- 
spond with the owner of the key pair. The public key can 

30 be used to verify a message signed with the private key 
or encrypt messages that can only be decrypted using 
the private key. The security of messages encrypted this 
way relies on the security of the private key, which must 
be protected against unauthorized use. 

35 [0011] The key pair in a certificate is bound to a user's 
name and other identifying information. When installed 
in an HTML browser, such as Netscape Navigator from 
Netscape Communication Inc. in California or Internet 
Explorer from Microsoft Corporation in Washington, the 

40 certificate functions as an electronic credential that sites 
being contacted can examine. This sometimes enables 
digital certificates to replace password dialogs for infor- 
mation or services that require membership or restrict 
access to particular users. For example, when one 

45 sends messages to a merchant web site, he signs the 
messages and encloses his digital ID to assure the re- 
cipient of the message that the message was actually 
sent by him. When the merchant receives digitally 
signed messages, the signer's digital ID is verified to de- 

so termine that no forgery or false representation has oc- 
curred. Generally, once a user obtains a certificate, he 
can set up his security-enhanced web or e-mail appli- 
cation to use the certificate automatically Figure 1 illus- 
trates the authentication process using the digital IDs 

55 between the client and the merchant server. 

[0012] The most secure use of authentication in- 
volves enclosing one or more certificates with every 
signed message. The receiver of the message would 
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verify the certificate using the certifying authority's pub- 
lic key and, now confident of the public key of the sender, 
verify the message's signature. There may be two or 
more certificates enclosed with the message, forming a 
hierarchical chain, wherein one certificate testifies to the 
authenticity of the previous certificate. At the end of the 
certificate hierarchy is a top-level certifying authority, 
which is trusted without a certificate from any other cer- 
tifying authority. The public key of the top-level certifying 
authority must be independently known, for example, by 
being widely published. In other words, a sender whose 
company is known to the receiver may need to enclose 
only one certificate (issued by the company), whereas 
a sender whose company is unknown to the receiver 
may need to enclose two or more certificates. For higher 
grade of security, it is a common practice to enclose just 
enough of a certificate chain so that the issuer of the 
highest level certificate in the chain is well known to the 
receiver. If there are multiple recipients, then enough 
certificates should be included to cover what each re- 
cipient might need. 

The Preferred Embodiment 

[001 3] Referring now to the drawings, in which like nu- 
merals refer to like parts throughout the several views. 
Figure 2 illustrates a schematic representation of a data 
network 100 in which the present invention may be prac- 
tised. The data network 100 comprises an airnet 102 
that is generally called wireless network and a landnet 
104 that is generally a landline network, each acting as 
a communication medium for data transmission there- 
through. The aimet 102, in which the data transmission 
is via the air, is sometimes referred to as a carrier net- 
work because each airnet is controlled and operated by 
a carrier, for example AT&T and GTE, each having its 
own communication scheme, such as CDPD, CDMA, 
GSM and TDMA for the airnet 102. The landnet 104 or 
the Internet, used interchangeably herein, may be the 
Internet, the Intranet or other private networks. Refer- 
enced by 106 is one of the mobile devices that can be 
a mobile device, a cellular phone, a landline telephone 
or an Internet appliance controller, capable of commu- 
nicating with the airnet 1 02 via an antenna 1 08. It is gen- 
erally understood that the airnet 102 communicates si- 
multaneously with a plurality of two-way communication 
devices, of which only a mobile device 106 is shown in 
the figure. Similarly, connected to the Internet 104 are 
a plurality of desktop PCs 110 and a plurality of server 
computers 112, though only one representative respec- 
tively is shown in the figure. The PC 110, as shown in 
the figure, may be a personal computer SPL 300 from 
NEC Technologies Inc. and runs a HTML Web browser 
via the Internet 104 using HTTP to access information 
stored in the web server 112 that may be a workstation 
from SUN Microsystems Inc. It is understood to those 
skilled in the art that the PC 110 can store accessible 
information therein so as to become a web server as 
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well. Between the Internet 104 and the aimet 102 there 
is a proxy server computer 114 performing data commu- 
nication therebetween. The proxy server computer 114, 
also referred to as link server or gateway server com- 
5 puter, may be a workstation or a personal computer and 
performs mapping or translation functions, for example, 
mapping from one protocol to another, thereby the mo- 
bile device 106 can be in communication with any one 
of the servers 112 or the PCs 110, respectively. 

w [0014] The communication protocol in the Internet 
104 is the well known HyperText Transfer Protocol (HT- 
TP) or HTTPS, a secure version of HTTP, and runs on 
TCP and controls the connection of a well known Hy- 
perText Markup Language Web browser, or HTML Web 

is browser in the server 114, to the Web server 112, and 
the exchange of information therebetween. HTTPS sup- 
ports SSL that is used mostly in secure and authenticat- 
ed communications between the HTML browsers and 
web servers. A common notation in the HTML browsers 

20 js the use of "htlps" before a universal resource locator, 
or URL, which indicates that an SSL connection will be 
established. In an SSL connection one side, preferably 
the server side, of the connection shall have a certificate 
that must be authenticated by the counterpart side. 

2S Each side then encrypts what it sends out using infor- 
mation from either its own, the other side or both side 
certificate, ensuring that only the intended recipient can 
decrypt it, and that the other side can be sure the data 
come from the place it claims to have come from, and 

30 that the message has not been tampered with. 

[0015] The communication protocol between the mo- 
bile device 106 and the proxy server 114 via the airnet 
102 is Handheld Device Transport Protocol (HDTP), or 
Secure Uplink Gateway Protocol (SUGP), which preter- 
ms ably runs on User Datagram Protocol (UDP) and con- 
trols the connection of a HDML Web browser, in the mo- 
bile device 106, to the proxy server 114; where HDML 
stands for Handheld Device Markup Language. HDML, 
similar to that of HTML, is a tag based document lan- 

40 guage and comprises a set of commands or statements 
specified in a card that specifies how information dis- 
played on a small screen of the mobile device 106. Nor- 
mally a number of cards are grouped into a deck that is 
the smallest unit of HDML information that can be ex- 

45 changed between the mobile device 106 and the proxy 
server 114. The specifications of HDTP and HDML Lan- 
guage Reference Version 2.0 are well known and readily 
available, their content being incorporated herein by ref- 
erence. The HDTP is a session-level protocol that re- 

so sembles HTTP but without incurring the overhead there- 
of and is highly optimized for use in thin devices that 
have significantly less computing power and memory. 
Further it is understood to those skilled in the art that 
the UDP does not require a connection to be established 

5S between a client and a server before information can be 
exchanged, which eliminates the need of exchanging a 
large number of packets during a session creation be- 
tween a client and a server. Exchanging a very small 
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number of packets during a transaction is one of the de- 
sired features for a mobile device with very limited com- 
puting power and memory to effectively interact with a 
landline device. 

[0016] The mobile device 106 comprises a display 
screen 1 1 6 and a keyboard pad 1 1 8. The hardware com- 
ponents including a microcontroller, a ROM and a RAM 
in the mobile phone 106 are known to those skilled in 
the art and so the hardware components are not de- 
scribed in detail herein. With the display screen 116 and 
the keypad 118, a user of the mobile device 106 can 
interactively communicate with the proxy server 114 
over the airnet 1 02. According to one embodiment, one 
portion of the compiled and linked processes of the 
present invention are stored in the ROM as a client mod- 
ule that causes the mobile device 106 to operate with 
the proxy server 114. Upon activation of a predeter- 
mined key sequence utilizing the keypad 1 1 8, the micro- 
controller initiates a communication session request to 
. the proxy server 11 4 using the client module in the ROM. 
Upon establishing the communication session, the mo- 
bile device 106 typically receives a single HDML deck 
from the proxy server 1 1 4 and stores the deck as cached 
in the RAM. As described above, an HDML deck com- 
prises one or more cards and each card includes the 
information required to generate a screen display on the 
display screen 116. The number of cards in a card deck 
is selected to facilitate efficient use of the resources in 
the mobile device 106 and in the airnet network 102. 
Generally, one of the cards is a choice card shows a 
sequence of frequently visited web sites and allows the 
user to choose one to make a secure and authenticated 
communication session with through the proxy server 
114. The process of using certificates to establish such 
communication session will be described below. 
[0017] .Referring now to Figure 3, there is depicted a 
representation of the present invention interacting with 
other parts or components in the data network. Refer- 
enced by 302, 304 and 306 are three representatives of 
a plurality of the mobile devices coupled to the airnet 
1 02, similarly referenced by 31 0, 31 2 and 31 4 are three 
representatives of a plurality of landline devices coupled 
to the landnet 104. The proxy server device which can 
be the one 1 1 4 in Figure 2, couples the airnet 1 02 to the 
landnet 104, therefore any mobile devices can commu- 
nicate with the landline devices via the airnet 102, the 
proxy server 114 and the landnet 104. To facilitate the 
description of the present invention, the internal block 
diagrams of the mobile device 302 and the link server 
114 are respectively illustrated. Other processes and 
hardware are known to those skilled in the art and are 
not illustrated in detail in the figure for clarity. 
[0018] Each of the mobile devices, such as the one 
302, is assigned to a device ID 316. The device ID 316 
can be a phone number of the device or a combination 
of an IP address and a port number, for example: 
204.163.165 132:01905 where 204.163 165 132 is the 
IP address and 01905 is the port number. The device 



ID 316 is further associated with a subscriber ID 318 
authorized by a carrier in the proxy server 114 as part 
of the procedures to activate the mobile device 302 by 
establishing a user account 324 in the proxy server 1 1 4. 

s The subscriber ID 318 may take the form of, for exam- 
ple, 861234567-10900_pn.mobile.att.net by AT&T 
Wireless Service. The subscriber ID 318 is a unique 
identification of the mobile device 302. In other words, 
each of the mobile devices 302, 304 and 306 has its own 

io unique device ID that corresponds to a subscriber ID 
indexing a respective user account in the proxy server 
114. The following description is based on the mobile 
device 302 and the associated account 324, it will be 
appreciated by those skilled in the art that the descrip- 

is tion is equally applied to a plurality of the mobile devices 
in communication simultaneously with the proxy server 
114. 

[0019] Theaccount324, indexed by the device ID 316 
or the subscriber ID 318 and identified by an address 

20 identifier such as a URL, is a data structure comprising 
user info 322, a certificate list 320 and a private key list 
326, wherein the user info 22 includes the account con- 
figuration and other account related information, such 
as username and password. The URL of the account 

25 may take the form of, for example, http://www.att.com/ 
Pocketnet which indicates that the airnet 102 is operat- 
ed by AT&T wireless service. The certificate list 320 con- 
tains or points to a list of designated certificates issued 
by one or more CAs and the private key list 326 contains 

30 a list of keys, each corresponding respectively to each 
certificate in the certificate list 320. All certificates in the 
certificate list 320 are exclusively associated with the 
particular account. Generally the proxy server 1 1 4 main- 
tains a large number of such user accounts, preferably 

35 kept in a database 328, each of the user accounts is 
respectively associated to each of the mobile devices 
that are subscribed with the same carrier and serviced 
by the proxy server 114. It can be appreciated that the 
certificates in one account are different from those in 

^0 other accounts because of the respective association of 
the certificates with each of the accounts therein. 
[0020] It has been described that it takes a noticeable 
length of time in a regular full-power desktop computer 
to obtain a certificate from a CA and generate a pair of 

45 keys; private and public keys therefor. To minimize the 
latency of obtaining a certificate with a mobile device, a 
certificate manager module (CMM) 342 maintains a cer- 
tificate database, preferably in the database 328, to re- 
serve a list ol undesignated but issued certificates, re- 

so ferred to as free certificates, from one or different CAs. 
Whenever a user account is created to activate a mobile 
device that requires one or more certificates to access 
certain web servers requiring a certificate, a certificate 
request (certRequest) signal is sent to the CMM 342 to 

55 fetch needed certificates from the certificate database. 
Upon receiving the fetched certificates from the certifi- 
cate database, the CMM 342 assigns the certificates to 
the particular account by attaching the device ID 316 



5 



BNSCOCID: <EP 0942568A2„I„> 



EP 0 942 568 A2 



and other account information, hence the fetched certif- 
icates become associated to the particular account and 
are placed in the certificate list 320. Meanwhile the CMM 
examines the number of the free certificates available 
in the certificate database, if the number is below a val- 
ue, for example 200 certificates, referred to as thresh- 
old, the CMM calls the HTTP module 330 to establish a 
connection to the appropriate CA via the landnet 1 04 to 
obtain new free certificates to fill up the certificate data- 
base till the level of the threshold is reached, as such 
there are always sufficient free certificates available in 
the certificate database to supply any new accounts with 
the ready-to-use free certificates. 
[0021] It can be now appreciated by those skilled in 
the art that the present invention uses the computing 
power in a proxy server to carry out the task of obtaining 
certificates asynchronously, apart from the tradition of 
obtaining certificates in local devices that normally have 
sufficient computing power, and further unlike the tradi- 
tion of physically storing the certificates in the local de- 
vices, the present invention maintains the certificates in 
a user account in the proxy server. Managing certificates 
in a proxy server for all clients makes it possible for the 
clients to access any secure web sites without demand- 
ing additional computing power and memory. Other ad- 
vantages will be further appreciated in the description 
below. 

[0022] The certificates are issued by a CA that can be 
any trusted central administration willing to vouch for the 
identities of those to whom it issues certificates and their 
association with a given key, for example, a company or 
a university may issue certificates to its own employees 
or its students. To accommodate the need of the mobile 
device 302 to obtain certificates from a CA other than 
the one that the CMM 342 uses to get the free certifi- 
cates from, the server module 340 allows the user there- 
of to log onto the user account 324 associated to the 
mobile device 302 through any computers; for example, 
a PC 314 coupled in the landnet 104. This is accom- 
plished by logging onto the user account 324 using the 
address identifier of the user account 324, for example: 
http://www.att.com/Pocketnet. To ensure that the ac- 
count 324 is accessed by an authorized user, a set of 
credential information, such as a usemame and pass- 
word, is required. The server module 340 through the 
HTTP module 330 will prompt for the username and 
password when the user connects the PC 314 to the 
URL using http://www.att.com/Pocketnet. Entries of a 
pair of matched username and password will be granted 
the permission to access the account. 
[0023] To provide flexibility and security to the ac- 
count, the username and password are fully adminis- 
trated by the user. The user of the mobile device 302 
can access the device's account 324 in the proxy server 
114 using the mobile device 302 that is equipped with a 
HDML browser. Knowing the URL of the account, the 
user depresses a predetermined key to cause the client 
module 332 to send a request comprising the URL and 
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the device ID 31 6 to UDP interface 336 that subsequent- 
ly establishes a communication session to the proxy 
servdr 114 using the HDTP. The request is received by 
the corresponding UDP interface 1 28 in the proxy server 
5 114 and carried out by the server module 340 to see if 
the device ID is authorized. The proxy server 114 then 
acknowledges the request with a response sent to the 
mobile device 302 for username and password. It 
should be noted that the response does not request from 

10 the user a pair of username and password to permit an 
access to the account, in fact the permission to access 
to the account has been granted by matching the device 
ID 316 in the request from the mobile device 302 and 
the stored device ID of the account 320 in the proxy serv- 
es er 114. Instead, the response allows the user to self- 
provision the account by entering a pair of new user- 
name and password. Once the account 320 receives the 
pair of new username and password, the account, i.e. 
the user info 322, is updated. After the self -provisioning 

20 procedure, the user may use the PC 31 4 which has pref- 
erably a sufficient computing power and equipped with 
a more familiar HTML browser to establish a communi- 
cation session using HTTP and the URL to the account. 
The newly provisioned username and password are en - 

25 tered in the PC 314 when prompted and sent over in a 
packet format to the proxy server 114 using HTTP in 
which the HTTP server 330 extracts the username and 
password and the server module 340 performs an au- 
thorization check with the user info 322 in the memory. 

30 if the entered username and password are matched, the 
authorization is granted so that the user or the PC 314 
is permitted to access the account 324. The user can 
now request a certificate from a specified CA and up- 
dates the certificate list 320 and the key list 326. The 

3S process of obtaining a certificate from a CA using an 
HTML browser is known to those skilled in the art and 
therefore is not to be described herein. It can be appre- 
ciated that, besides the capabilities provided by the 
CMM, the self-provisioning capability allows a user to 

40 tailor the certificates to his own needs while still relying 
on the proxy server to keep all the certificates designat- 
ed to the mobile device 302. 

[0024] Based on Figure 3, Figures 4A and 4B demon- 
strate an example in which the user of the mobile device 

is 302 requests certificates from user-specified CAs. After 
a predetermined key is pressed, the mobile device 302 
uses HDTP to make a request to connect to the proxy 
server 1 1 4 using the URL of the account designed to the 
mobile device: 302861 23456-1 0900_pn.mobile.xyz. 

so net. The device ID 86123456-10900 is extracted from 
the request and verified that there is an account 324 in- 
dexed by the same device ID 86123456-10900. Upon 
the verification, the user of the mobile device 302 is 
prompted for a set of username and password. It has 

55 been described that username and password are not 
the required information for the mobile device 302 to ac- 
cess the account 324, rather the user is given a permis- 
sion to administrate the username and password. If the 
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user does not enter any new username and password, 
the username and password in the user account 324 
stays the same. If the user enters a set of new username 
and password, for example; username = "smith", and 
the password = "123456", theaccount324 is updated 5 
with the new username and password. The user can 
now go to any computer in the landnet 1 04 to manipulate 
the account 324. The PC 314 is equipped with a HTML 
browser providing a full graphical user interface that al- 
lows the user to manipulate the account 324 much more io 
efficiently. The PC 314 establishes an HTTP connection 
using the URL, for example, mobile.xyz.net, of the gate- 
way 354 in the server module 340 to all the user ac- 
counts in the proxy server 114. The user is prompted at 
the PC 314 for a set of username and password. The is 
user must enter "smith" for the username and "123456" 
for the password to get through the gateway 354. Upon 
receiving the entered username and password, the 
gateway 354 compares them with the ones in the ac- 
count 324. If there is a mismatch, the PC or the user is 20 
not permitted to access the account 324. If the entered 
username and password match the ones in the account 
324, the gateway 354 grants permission to the PC 314. 
The user of the PC 314 can now use the HTML browser 
to request special certificate from a special CA 358 by 25 
providing a URL thereof and place the certificate the ac- 
count 324 for the mobile device 302 to use. 
[0025] According to one embodiment of the present 
invention, the certificate list may be implemented as a 
pointer to a certificate table 368. As is shown in Figure 30 
4B, it can be appreciated to those skilled in the art that 
the use of pointer provides flexible capacity of the cer- 
tificate list. The certificate index 370 provides a space 
to store all the certificates and the corresponding URL 
list 372 associated URL for the specially requested cer- 35 
tificates in the certificate index 370. There are a few 
service web sites that accept certificates from certain 
CAs. For example, a financial web site identified by http: 
//www. finacial.com only takes certificates signed by CA 
S1 . By self-provisioning the account, the user can spe- 40 
cifically request the certificate from CA S1 and place the 
certificate in the certificate table 368. In a later use, the 
mobile device 302 sends a request to establish a con- 
nection to http://www.finacial.com. When the request 
comprising http://www.finacial.com is received in the 4 & 
proxy server device 114, the URL is used to retrieve the 
corresponding certificate, the certificate by CA S1 in this 
case. Along with the certificate by CA S1, the mobile 
device 302 can access the web identified by http://www. 
finacial.com. Generally, the certificate 382 acquired by so 
the CMM 342 is a generic one acceptable to many web 
sites and not associated with a particular URL. In other 
words, the certificate table 368 may have a number of 
special certificates, such as referenced by 376, 378 and 
380, specifically requested by the user and one or more 55 
generic certificates, such as referenced by 382, auto- 
matically acquired by the CMM 342. 
[0026] Figure 5 illustrates a block diagram of various 
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components in the CMM 342. As described above, the 
CMM maintains a fixed number of free certificates in the 
certificate database and starts to get new certificates 
through the HTTP server 330 from the CA as soon as 
the number of the free certificates in the certificate da- 
tabase becomes lower than the threshold. Referenced 
by 402 is a certificate engine that manages the opera- 
tions of other components in CMM 342. When the mo- 
bile device 302 is activated, the account thereof is re- 
quested to load with one or more certificates. After a free 
certificate is fetched from the certificate database and 
upon detecting that the number of available free certifi- 
cates in the certificate database below the threshold, the 
engine 402 triggers the distinguished name generator 
404, or DN generator, to generate a unique distin- 
guished name for a new certificate to be created. 
[0027] The distinguished name is the standard form 
of naming in the CCITT X.509 standard. A distinguished 
name comprises one or more relative distinguished 
names, and each relative distinguished name is com- 
prised of one or more attribute-value assertions. Each 
attribute-value assertion consists of an attribute identi- 
fier and its corresponding value information, e.g. Coun- 
tryName = US, Organization =XYZ, Inc. or Organiza- 
tionUnit = XYZ Service Division. The use of the distin- 
guished names is intended to identify entities in a X.500 
directory tree that is now being used to implement "white 
pages" for the tnternet~a directory of people, comput- 
ers, services, and electronic mail addresses. The direc- 
tory is organized hierarchically: international organiza- 
tions and countries are at the top; countries are subdi- 
vided into states or provinces, which in turn are subdi- 
vided in various ways. A relative distinguished name is 
the path from one node to a subordinate node of the 
directory tree. The entire distinguished name traverses 
a path from the root of the tree to an end node that rep- 
resents a particular entity. A goal of the directory is to 
provide an infrastructure to uniquely name every com- 
munication entity in the Internet, hence the "distin- 
guished" in the distinguished name. 
[0028] To ensure that the distinguished name gener- 
ated by the distinguished name generator 404 is asso- 
ciated eventually with a user account, the distinguished 
name prefix generator 406 generates a prefix for the dis- 
tinguished name. The prefix is generally a concatena- 
tion of a timestamp and a subscriber ID, for example, 
861765228-9, wherein the timestamp indicates when 
the certificate request is made and the subscriber ID is 
to be assigned to a mobile device when it is activated. 
With the prefix from the distinguished name prefix gen- 
erator 406, the distinguished name generated from the 
distinguished name generator 404 must be unique. In 
order words, each of the free certificates in the certificate 
database has its own name and all the names must be 
distinguished. 

[0029] The Certificate Engine 402 then invokes the 
key pair generator 412, or KP generator, to generate a 
pair of public and private keys. It does so by using a set 
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of library functions which generates the private key 
based on the public key that is generated with supplied 
seed information. To conform to the industry standard, 
the set of library used in the key pair generator 412 is 
supplied by RSA Data Security, Inc. having an address 
of 100 Marine Parkway, Suite 500, Redwood City, CA 
94065. The generated keys are generally in the form of 
a sequence of binary numbers, such as 
1110101100001. ..00101 and unlikely to be duplicated 
without knowing the source to generate them. To gen- 
erate a pair of unique private and public keys, a random 
number, as the source, must be provided according to 
the set of library. It is understood to those skilled in the 
art that there are many ways to get the random number 
One of the commonly used methods is to generate the 
random number through a one-way hash function from 
a noise source that may be hard-coded or from network 
traffic information. The one-way means that it is signifi- 
cantly easier to perform in one direction (the forward di- 
rection) than in the opposite direction (the inverse direc- 
tion), which makes it unlikely to derive the private key 
from the public key. One example of such hash functions 
is to multiply a value itself a certain number of times and 
followed by a modulo operation. 

[0030] The certificate engine 402 creates a new entry 
for the certificate in the certificate database and the cor- 
responding private key from the key pair is stored in the 
new entry, meanwhile the certificate engine 402 uses 
the generated distinguished name and the public key 
obtained from the key pair generator 41 2 to generate a 
certificate signing request or CSR. The CSR is a public 
standard format for requesting certificates from a CA. 
The CSR contains, among other things, the public key 
that is to be certified by the CA and the distinguished 
name associated with the public key. The CSR is a bi- 
nary block of data packaged in a certificate request in a 
standard form that is then sent to the CA through the 
HTTP module 330 using HTTP. 

[0031] Upon receiving the certificate request, the CA 
verifies the supplied information therein and attests to 
the validity of the user's public key along with other in- 
formation by signing the certificate. The C A then issues 
a certificate response, which may contain the signed 
certificate or an error If the certificate response contains 
an error, that means the certificate being requested fails, 
a new process must be restarted. When the certificate 
response comes back from the CA, the certificate en- 
gine 402 extracts the distinguished name from the re- 
ceived certificate and updates the corresponding entry 
in the certificate database through the certificate storage 
library 408. At this point that entry contains the signed 
certificate which has the public key embedded in it and 
the corresponding private key, which has been referred 
to as the free certificate. 

[0032] When the mobile device 302 is activated, a re- 
quest is submitted for creating a certificate for the de- 
vice. The certificate engine 402 fetches a free certificate 
from the certificate database and associates it with the 



device ID. The association is performed by making an 
entry in a separate temporary table called 
device_cert_map_tbl, preferably in a RAM of the proxy 
server 114. 

5 [0033] The certificate storage (CS) library 408, or CS 
library, is used to administrate the certificate database 
and from time to time receives certificate revocations 
lists from CAs. A certificate revocation list (CRL) is a list 
of certificates that have been revoked before their 

10 scheduled expiration date. There are several reasons 
why a certificate might need to be revoked and placed 
on a CRL. For instance, the key specified in the certifi- 
cate might have been compromised, or, the user spec- 
ified in the certificate may no longer have authority to 

is use the key. To be more specific, a user name associ- 
ated with a key is "Mr. Smith, Vice President, XY2 Corp. 
" If Mr. Smith left the company, the company may not 
want him to be able to sign messages with that key, and 
therefore, the company would place the certificate on a 

20 CRL. When verifying a signature, one can check the rel- 
evant CRL to make sure the signer's certificate has not 
been revoked. Whether it is worth the time to perform 
this check depends on the importance of the signed doc- 
ument. The CRL is maintained by the CA and provides 

25 information about revoked certificates that were issued 
by the CA. The CRL, however, only lists current valid 
certificates, since expired certificates should not be ac- 
cepted in any case; when a revoked certificate is past 
its original expiration date, it is removed from the CRL. 

30 Although a CRL is maintained in a distributed manner, 
there may be central repositories for a CRL, that is, net- 
work sites containing the latest CRLs from many organ- 
izations. 

[0034] The certificate library 408 receives such CRL 

35 and informs the certificate engine 402 to take action 
when any certificates maintained by the CMM 342 is in 
the list. It is described that the CMM 342 maintains a 
certificate database housing a fixed number of free cer- 
tificates. When the CMM 342 associates a certificate 

40 from the certificate database to a user account, the as- 
sociated certificate must be valid. This is guaranteed by 
first consulting with the CRL through the CS library 408. 
If a fetched certificate from the certificate database is 
somehow on the CRL, the fetched certificate is discard- 

45 ed and a next certificate is fetched from the certificate 
database. A check-up of the fetched certificate with the 
CRL is always performed in the CS library 408 before 
the fetched certificate is associated to the account. It is 
understood to those skilled in the art that the check-up 

50 with the CRL may be performed by an exhaustive com- 
parison. The time or computation it takes to do the 
check-up regardless of the length of the CRL is afford- 
able as all are being carried out in the proxy server 114 
asynchronously with the mobile device 416. 

55 [0035] In an example of operations in the CMM, the 
main() function creates a TCertEngine object and calls 
initialized by a function named Initialize which creates 
the necessary threads to service HTTP client based re- 
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quests. It also creates threads that monitor certificates 
in the certificate database. When the thread is created 
it monitors available resources and calls GenerateCert 
in TCertHttpProto to create certificates. This thread us- 
es TDBCertPool to create a new entry in database for s 
the certificate pool. 

[0036] The function GenerateCert gets a new Distin- 
guished Name from the Distinguished Name Generator. 
It also gets a new public/private key pair from the Key 
Pair Generator. GenerateCert used this information to 10 
construct a CSR. It then issues a request to a CA over 
HTTP using SendCSR method in THttpCertRequest. 
When the certificate response comes back from the C A, 
it updates the entry in the free pool using TDBCertPool. 
[0037] When a free certificate needs to be associated is 
with a user account, the HandleCreateCert method in 
TCertCreateCallback is invoked. This method extracts 
a new certificate from the free certificate pool using func- 
tions in TDBCertPool. The method then calls functions 
in TDBDeviceMap to make a new entry in the 20 
device_cert_map_tbl. It then returns a response to the 
caller. The Reissuer thread, TCertReissueThread, calls 
ReissueCert in TCertHttpProto to have certificates reis- 
sued. It calls methods on TDBCertPool to TDBDeviceM- 
ap to revoke certificates in the free pool and those that 2s 
are associated with the device. 

[0038] Figures 6A and 6B illustrates an operational 
flowchart of the centralized certificate management sys- 
tem in the present invention and should be understood 
in conjunction with Figures 3 and 4. Complied and linked 30 
processes of the present invention are loaded into a 
proxy server 502 and cause the proxy server 502 to per- 
form the centralized certificate management. It is under- 
stood to those skilled in the art that a proxy server is a 
server computer or device, generally equipped with suf- 35 
ficient computing power and memory, that is loaded with 
applications that cause the device to service other com- 
puting devices, hence the applications therein are com- 
monly referred to as the server and the device itself is 
referred to herein as server device. The computing de- 40 
vices in the present invention are the thin devices that 
may be mobile devices, cellular phones and the Internet 
appliance controllers. 

[0039] At 504, the CMM 324 cause the server device 
502 to maintain a certificate database that is preferably 45 
stored in a local storage driver in the server device 502. 
The certificate database reserves a fixed number of free 
certificates signed by a C A yet to be associated to a user 
account or a thin client. By maintaining the ready-to-use 
free certificates in the database, the thin client can get so 
a certificate associated thereto without a noticeable time 
delay, needed computing power and memory. At 506, 
the number of the availablefree certificates is examined. 
If the number drops, a process to get new certificate 
starts at 510. It should be understood that the number ss 
of the free certificates in the certificate database is 
dropped sometime because of the certificate updating 
at 508. To ensure that the certificates to be associated 
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with user accounts are always valid, the CS library 408 
constantly updates the free certificates in the certificate 
database according to a certificate updating message 
received from a CA or commonly used repository site. 
The certificate message may comprise a CRL or insert/ 
delete query, which causes the CMM 324 to discard 
some of the free certificates, hence the number of the 
free certificates decreases. In any case, the CMM 324 
tries to maintain the level of the free certificates in the 
certificate database by getting new certificates from a 
CA. When the process to get a new certificate starts, the 
CMM 324 first gets a distinguished name for the new 
certificate by calling the DN prefix generator 406 and 
DN generator 404 at 510 and 51 2 and then calls KP gen- 
erator 412 to generate a pair of private key and public 
key therefor at 514. A certificate request is formed at 
516 to include a CSR comprising the generated distin- 
guished name and the public key. At 518, the CMM 342 
communicates with the C A using HTTP through the HT- 
TP server 330. Upon receiving the certificate request, 
the C A attests to the validity of the public key along with 
other information by signing the certificate and returns 
a certificate response to the CMM 342, thus a signed 
certificate is created at 520. The signed certificate is de- 
posited as a free certificate to the certificate database 
at 522. Logically the number of the free certificates is 
incremented by one and compared with the fixed 
number or threshold. If the incremented number is still 
below the threshold, the process to get a new certificate 
is repeated from 51 0 till the number of the free certificate 
in the certificate database reaches the threshold. 
[0040] Meanwhile the CMM 342 maintains a plurality 
of user accounts at 536, each preferably assigned to 
one thin client. Each of the accounts has one or more 
certificates exclusively associated with the account. 
When a thin client is activated to be serviced by the serv- 
er device 502, a new user account is established there- 
for at 538. As described before, the user account may 
comprise a device ID, a subscriber ID, user info, a cer- 
tificate list and a private key list. The device ID is a piece 
of information that helps the server device 502 to rec- 
ognize which thin client device it is supposed to service 
and entered when the thin device is activated. The user 
info contains inform regarding the account configuration 
and the services that the thin client needs. The subscrib- 
er ID, the certificate list and the private key list are ob- 
tained when a certificate is associated thereto. At 540, 
a request to get a certificate is made. Upon receiving 
the request at 542, the CMM 342 fetches a valid free 
certificate from the certificate database and associates 
the free certificate to the account. 
[0041] The present invention includes a method of 
self provisioning. Specifically, a user may attempt to 
self -provision as illustrated at step 544 in Figure 6B. 
First, the attempts to access a user account by logging 
onto the account. If the user is logging in using the thin 
client device that has a device ID, the access is quickly 
authenticate. If the user is logging in using a PC con- 
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nected to the Internet, then the user must enter the cur- 
rent username and password. Alter obtaining access, 
the user may change the username and/or password at 
step 572. The user can then access the account from 
the thin client or another computing device to request a 5 
certificate from a user-specified CA at 578. 
[0042] After the thin client is activated by establishing 
the account having one or more certificates in the server 
device 502 : it is now possible for the thin client to estab- 
lish secure and authenticated communication session io 
with some secure web sites to conduct private commu- 
nication therebetween. At 550, the server device 502 re- 
ceives a session request from the thin client to establish 
a secure and authenticated communication session with 
a web site identified by a URL The session request *s 
comprises the device ID of the thin client in order for the 
server device 502 to recognize the thin device and con- 
sequently authorize such request therefrom. At 552 : the 
device ID is extracted from the session request and 
compared with Ihe device ID in the user account. If the 20 
devices IDs are matched, the thin device is authorized 
and further examined per the corresponding account 
thereof. At 544, the certificate in the matched account 
is fetched to be included in the session request that is 
sent to the desired web site using HTTPS. At 558, an 25 
authentication between the thin client and the contacted 
web site is carried out by examining each other's certif- 
icate. If each certificate is trusted, a session key is re- 
sulted therefrom and used to encrypt information to be 
exchanged between the thin client and the web site, 30 
hence a secure and authenticated communication is es- 
tablished. 

[0043] The present invention has been described in 
sufficient detail with a certain degree of particularity. It 
is understood to those skilled in the art that the present 35 
disclosure of embodiments has been made by way of 
example only and that numerous changes in the ar- 
rangement and combination of parts as well as steps 
may be resorted without departing from the spirit and 
scope of the invention as claimed. Accordingly, the 40 
scope ol the present invention is defined by the append- 
ed claims rather than the forgoing description of embod- 
iments. 



Claims 

1 . A method for managing centralized certificates in a 
proxy server device for a plurality of thin client de- 
vices coupled to the proxy server through a data so 
network, the method comprising: 
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maintaining a user account database accessi- 
ble by the proxy server, the user account data- 
base comprising a plurality of user accounts, 
each of the thin client devices associated with 
one of the user accounts wherein each of the 
user accounts comprises a device ID, a list of 
public and private keys assigned to the user ac- 
count, and a list of certificates assigned to the 
user account; and 

adding at least one certificate taken out from 
the free certificate database to each user ac- 
count in the user account database. 

2. The method as recited in claim 1 , wherein the main- 
taining the certificate database in the proxy server 
comprises: 

receiving a certificate request when the number 
of free certificates in the certificate database is 
lower than a low threshold number; and 
generating a new certificate wherein the gener- 
ating the new certificate comprises, 

generating a distinguished name for the 
new certificate; 

generating a new private key and a new 
public key for the new certificate; 
sending the certificate request to the CA 
wherein the certificate request comprises 
the generated new public key; and 
receiving the new certificate signed by the 
CA; and 

depositing the new certificate in the free certif- 
icate database. 



3. The method as recited in claim 1 or 2, wherein the 
maintaining the user account database comprises: 

retrieving one of the free certificates from the 
free certificate database when a new thin client 
device is activated; 

establishing a new user account related to a 
new device ID and a new subscriber ID; and 
associating the retrieved free certificate and the 
corresponding private key and public key with 
the new user account; 

4. The method as recited in any preceded claim further 
comprising: 

updating a user account in the user account da- 
tabase associated with a valid device ID upon 
receiving a newly provisioned username and 
password from a thin ciient device having the 
valid device ID. 



maintaining a free certificate database acces- 
sible by the proxy server the free certificate da- 
tabase comprising a plurality of free certificates ss 
issued by a Certificate Authority(CA) wherein 
each of the free certificates has a correspond- 
ing public key and a corresponding private key; 
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5. The method as recited in claim 4 wherein the user 
account in the user account database is accessible 
with the newly provisioned usernarne and password 
from a computer coupled to the proxy server 
through the Internet. 



11. The apparatus as recited in claim 10, wherein the 
certificate update request further comprises an in- 
sert/delete query. 



6. An apparatus for managing centralized certificates 
in a proxy server device for a plurality of thin client 
devices over a data network, the apparatus com- 
prising: io 

a certificate manager module for generating 
free certificates; 

a free certificate database coupled to the cer- 
tificate manager module for storing the free cer- is 
titicates from the certificate manager module 
until reaching an upper threshold; 
a user account database, the user account da- 
tabase accessible by the proxy server device, 
the user account database comprising a plural- 2° 
ity of user accounts, each of the thin client de- 
vices associated with one of the user accounts 
wherein each of the user accounts comprises 
a device ID and a list of certificates assigned to 
the user account; and 25 
a certificate assigning module for associating 
one of the free certificates in the free certificate 
database to a new user account in the user ac- 
count database associated with a newly acti- 
vated thin client device. 30 



7. The apparatus as recited in claim 6; wherein the 
certificate manager module comprises: 

a certificate engine communicating with the 35 
certificate assigning module; 
a name generator generating a unique name 
for a new certificate; 

a key pair generator generating a private key 
and a public key for the new certificate; and 
a certificate request module for contacting a 
certificate authority for the new certificate, 
wherein the certificate request comprises the 
public key and the unique name. 

45 

8. The apparatus as recited in claim 7, wherein the 
name generator comprises a distinguished name 
generator that combines a limestamp along with a 
subscriber ID. 

so 

9. The apparatus as recited in claim 8; wherein the 
certificate manager module updates the free certif- 
icate database upon receiving certificate update re- 
quest. 

55 

10. The apparatus as recited in claim 9, wherein the 
certificate update request comprises a certificate 
revocation list. 
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Client verifies the server's 
digital ID. If requested, 
the client sends its digital 
ID in response to the 
server's request 



When authentication is 
complete, the client sends 
the server a session key 
encrypted using the 
server's public key 




Server responds, sending the 
client its digital ID, the server may 
also request the client's digital 
ID for client authentication 



I If client digital ID is authenticated, 
j server accepts the request, 
I otherwise server denies the 
I request. 




HOnce a session key is established, 
secure communications commence 
between the client and the server 

V~| Fig- 1 
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